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Priority Claim 

TWs application is a continuation-in-part of U.S. Patent Application Serial No. 
09/518,492\jtled "System and Method for Programmatically Creating a Graphical 
Program", filed March 3, 2000, whose inventors were Ram Kudukoli, Robert Dye, Melanie 
5 Jensen, and Yumiko Kawachi, which claims benefit of priority of U.S. provisional Patent 
Application Serial No. 6Gh>49,943 titled "System and Method for Programmatically 
Creating a Graphical Program" jmd filed August 19, 1999. 

This is also a continuation-in-part of U.S. Patent Application Serial No. 09/595,003 
titled "System and Method for Automatically Generating a Graphical Program to 
10 Implement a Prototype", filed June 13, 2000, whose inventors were Nicolas Vazquez, 
Jeffrey L. Kodosky, Ram Kudukoli, Kevin L. Schultz, Dinesh Nair, Christophe Caltagirone. 

Field of the Invention 

The present invention relates to the field of graphical programming, and more 
15 particularly to a system and method for programmatically generating a second graphical 
program based on a first graphical program, wherein the second graphical program 
implements at least a portion of the functionality of the first graphical program. 

Description of the Related Art 

20 Traditionally, high level text-based programming languages have been used by 

programmers in writing application programs. Many different high level programming 
languages exist, including BASIC, C, Java, FORTRAN, Pascal, COBOL, ADA, APL, etc. 
Programs written in these high level languages are translated to the machine language level 
by translators known as compilers or interpreters. The high level programming languages 

25 in this level, as well as the assembly language level, are referred to herein as text-based 
programming environments. 

Increasingly, computers are required to be used and programmed by those who are 
not highly trained in computer programming techniques. When traditional text-based 
programming environments are used, the user's programming skills and ability to interact 




Atty. Dkt. No.: 5150-48000 



Page 1 



Conley, Rose & Tayon, P.C. 



with the computer system often become a limiting factor in the achievement of optimal 
utilization of the computer system. 

There are numerous subtle complexities which a user must master before he can 
efficiently program a computer system in a text-based environment. The task of 
5 programming a computer system to model or implement a process often is further 
complicated by the fact that a sequence of mathematical formulas, mathematical steps or 
other procedures customarily used to conceptually model a process often does not closely 
coirespond to the traditional text-based programming techniques used to program a 
computer system to model such a process. In other words, the requirement that a user 

10 program in a text-based programming environment places a level of abstraction between the 
user's conceptualization of the solution and the implementation of a method that 
accomplishes this solution in a computer program. Thus, a user often must substantially 
master different skills in order to both conceptualize a problem or process and then to 
program a computer to implement a solution to the problem or process. Since a user often 

15 is not fully proficient in techniques for programming a computer system in a text-based 
environment to implement his solution, the efficiency with which the computer system can 
be utilized often is reduced. 

Examples of fields in which computer systems are employed to interact with 
physical systems are the fields of instrumentation, process control, industrial automation, 

20 and simulation. Computer measurement and control of devices such as instruments or 
industrial automation hardware has become increasingly desirable in view of the increasing 
complexity and variety of instruments and devices available for use. However, due to the 
wide variety of possible testing and control situations and environments, and also the wide 
array of instruments or devices available, it is often necessary for a user to develop a custom 

25 program to control a desired system. 

As discussed above, computer programs used to control such systems traditionally 
had to be written in text-based programming languages such as, for example, assembly 
language, C, FORTRAN, BASIC, etc. Traditional users of these systems, however, often 
were not highly trained in programming techniques and, in addition, text-based 
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programming languages were not sufficiently intuitive to allow users to use these languages 
without training. Therefore, implementation of such systems frequently required the 
involvement of a programmer to write software for control and analysis of instrumentation 
or industrial automation data. Thus, development and maintenance of the software 
5 elements in these systems often proved to be difficult. 

U.S. Patent Nos. 4,901,221; 4,914,568; 5,291,587; 5,301,301; and 5,301,336; 
among others, to Kodosky et al disclose a graphical system and method for modeling a 
process, i.e., a graphical programming environment which enables a user to easily and 
intuitively model a process. The graphical programming environment disclosed in Kodosky 

10 et al can be considered a higher and more intuitive way in which to interact with a 
computer. A graphically based programming environment can be represented at a level 
above text-based high level programming languages such as C, Basic, Java, etc. 

The method disclosed in Kodosky et al allows a user to construct a diagram using a 
block diagram editor. The block diagram may include a plurality of interconnected icons 

15 such that the diagram created graphically displays a procedure or method for accomplishing 
a certain result, such as manipulating one or more input variables and/or producing one or 
more output variables. The diagram may have one or more of data flow, control flow 
and/or execution flow representations. In response to the user constructing a diagram or 
graphical program using the block diagram editor, data structures may be automatically 

20 constructed which characterize an execution procedure which corresponds to the displayed 
procedure. The graphical program may be compiled or interpreted by a computer. 

Therefore, Kodosky et al teaches a graphical programming environment wherein a 
user places or manipulates icons and interconnects or "wires up" the icons in a block 
diagram using a block diagram editor to create a graphical "program." A graphical program 

25 for measuring, controlling, or modeling devices, such as instruments, processes or industrial 
automation hardware, or for modeling or simulating devices, may be referred to as a virtual 
instrument (VI). Thus, a user can create a computer program solely by using a graphically 
based programming environment. This graphically based programming environment may 
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be used for creating virtual instrumentation systems, modeling processes, control, 
simulation and numerical analysis, as well as for any type of general programming. 

In creating a graphical program, a user may create a front panel or user interface 
panel. The front panel may include various user interface elements or front panel objects, 
such as controls and/or indicators, that represent or display the respective input and output 
that will be used by the graphical program or VI, and may include other icons which 
represent devices being controlled. The front panel may be comprised in a single window 
of user interface elements, or may comprise a plurality of individual windows each having a 
user interface element, wherein the individual windows may optionally be tiled together. 
When the controls and indicators are created in the front panel, corresponding icons or 
terminals may be automatically created in the block diagram by the block diagram editor. 
Alternatively, the user can place terminal icons in the block diagram which may cause the 
display of corresponding front panel objects in the front panel, either at edit time or later at 
run time. As another example, the front panel objects, e.g., the GUI, may be embedded in 
the block diagram. 

During creation of the block diagram portion of the graphical program, the user may 
select various function nodes or icons that accomplish his desired result and connect the 
function nodes together. For example, the function nodes may be connected in one or more 
of a data flow, control flow, and/or execution flow format. The function nodes may also be 
connected in a "signal flow" format, which is a subset of data flow. The function nodes 
may be connected between the terminals of the various user interface elements, e.g., 
between the respective controls and indicators. Thus the user may create or assemble a 
graphical program, referred to as a block diagram, graphically representing the desired 
process. The assembled graphical program may be represented in the memory of the 
computer system as data structures. The assembled graphical program, i.e., these data 
structures, may then be compiled or interpreted to produce machine language that 
accomplishes the desired method or process as shown in the block diagram. 

Input data to a graphical program may be received from any of various sources, such 
as from a device, unit under test, a process being measured or controlled, another computer 
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program, or from a file. Also, a user may input data to a graphical program or virtual 
instrument using front panel controls. This input data may propagate through the data flow 
block diagram or graphical program and appear as changes on the output indicators. In an 
instrumentation application, the front panel can be analogized to the front panel of an 
instrument. In an industrial automation application the front panel can be analogized to the 
MMI (Man Machine Interface) of a device. The user may adjust the controls on the front 
panel to affect the input and view the output on the respective indicators. Alternatively, the 
front panel may be used merely to view the input and output, or just the output, and the 
input may not be interactively manipulable by the user during program execution. 

Thus, graphical programming has become a powerful tool available to 
programmers. Graphical programming environments such as the National Instruments 
Lab VIEW product have become very popular. Tools such as Lab VIEW have greatly 
increased the productivity of programmers, and increasing numbers of programmers are 
using graphical programming environments to develop their software applications. In 
particular, graphical programming tools are being used for test and measurement, data 
acquisition, process control, man machine interface (MMI), supervisory control and data 
acquisition (SCADA) applications, simulation, machine vision applications, and motion 
control, among others. 

Many different graphical programming environment applications are in use today, 
including Lab VIEW, DasyLab, and Diadem from National Instruments, Simulink from The 
Math Works, and VEE from Agilent, among many others. The process of developing a 
graphical program in various graphical programming environments is similar in many ways. 
For example, as described above, the user typically creates a block diagram including 
various nodes and/or programmatic structures. However, the programs developed in these 
various programming environments may differ in many aspects. For example, the various 
nodes available for inclusion in a block diagram may differ from one environment to 
another. Thus, a graphical program developed using a particular programming environment 
may be said to be "associated" with that programming environment. Typically, it is not 
possible to use a first graphical program associated with a first programming environment 
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in a second programming environment. In other words, the second programming 
environment cannot be used to perform tasks such as editing, executing, or debugging the 
first graphical program. 

Thus, in order to use the first graphical program in the second programming 
environment, the first graphical program needs to be translated into a second graphical 
program associated with the second programming environment. In other words, a second 
graphical program must be created, wherein the second graphical program implements the 
functionality of the first graphical program. However, in the prior art, there is no system 
and method for automatically creating the second graphical program based on the first 
graphical program. In order to port a graphical program to a new graphical programming 
environment, users are currently forced to manually create a new graphical program 
associated with the new graphical programming environment. This typically entails 
recreating the block diagram of the original graphical program, e.g., to use nodes and 
programming conventions available in the new graphical programming environment. This 
can be a difficult, time-consuming, and error-prone task, especially when a large number of 
graphical programs must be ported to the new programming environment. Thus, a system 
and method to automate this process are desired. 
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Summary of the Invention 

One embodiment of the present invention comprises a system and method for 
programmatically generating a second graphical program based on a first graphical 
program. The first graphical program may be associated with a first programming 
environment. For example, a user may have interactively created the first graphical 
program from within the first programming environment, e.g., by using an editor to place 
and connect various nodes on a block diagram, such that the interconnected nodes visually 
indicate functionality of the first graphical program. The method may operate to 
automatically, i.e., programmatically, generate a second graphical program based on the first 
graphical program, such that the second graphical program is associated with a second 
programming environment. The method may generate the second graphical program 
programmatically, without relying on user input, or using some user input. For example, 
the system may prompt for user input to determine various options to use in automatically 
generating the second graphical program. 

The second graphical program may implement the functionality of, or a portion of 
the functionality of, the first graphical program. The method preferably generates the 
second graphical program such that the second programming environment is operable to 
treat the second graphical program identically to a graphical program interactively 
developed by a user using the second programming environment. Thus, once the second 
graphical program has been generated, the user may use the second programming 
environment to edit the second graphical program, execute the second graphical program, 
etc. 

In the preferred embodiment, the method receives information specifying the first 
graphical program, examines the information, and generates the second graphical program 
based on the information. The information specifying the first graphical program may be 
the first graphical program itself, e.g., may be the data structures or files that comprise the 
first graphical program. For example, during creation of the first graphical program, the 
first programming environment typically creates one or more files or data structures which 
specify or comprise the first graphical program. In various embodiments, these files may 
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comprise text and/or binary information. The method may receive the information 
specifying the first graphical program from one or more of these files. For example, the 
information may include information specifying a set of nodes comprised in the first 
graphical program, interconnections among these nodes, programmatic structures such as 
5 loops comprised in the first graphical program, etc. The information may also include 
information specifying a user interface for the first graphical program. 

In various embodiments, the information specifying the first graphical program may 
be received in any of various formats or file types, e.g., depending on the particular 
programming environment used to create the first graphical program. For example, the 

10 information may include information received from one or more binary files specifying 
various data structures which the first programming environment uses to directly represent 
the first graphical program. In another embodiment, the information may include abstract 
information describing the first graphical program, e.g., abstract information stored in a text 
file which the first programming environment is operable to generate. For example, such 

15 abstract information may fully specify the first graphical program, but the first programming 
environment may also maintain other files which allow the first programming environment 
to more efficiently manipulate the first graphical program, e.g., when editing or compiling 
the program. 

In the preferred embodiment, the method is operable to analyze the received 
20 information specifying the first graphical program in order to construct an abstract 
representation of the first graphical program. In other words, one or more data structures 
representing the first graphical program may be programmatically constructed based on the 
received information. Once the abstract representation of the first graphical program has 
been constructed, the method may programmatically generate the second graphical program, 
25 using this representation. 

The method may generate the second graphical program programmatically, without 
relying on user input, or may prompt for user input to determine various options to use in 
generating the second graphical program. For example, in various embodiments the user 
may specify options such as whether to generate the second graphical program so that it 
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resembles the first graphical program as closely as possible, e.g., in the layout and 
interconnections among block diagram nodes, or whether to perform optimizations or 
modifications where possible or necessary, e.g., to facilitate downloading the second 
graphical program to a hardware device for execution. 

The user may also be prompted for information enabling various aspects of the first 
graphical program to be translated. For example, the first graphical program may include 
functionality not natively supported by the programming environment of the second 
graphical program or may include functionality for which the method lacks the necessary 
knowledge to translate. Thus, the user may be prompted to specify equivalent functionality 
to be included in the second graphical program, e.g., by specifying one or more nodes 
supported by the second graphical program's programming environment or by specifying an 
external code module with which the second graphical program can interface, such as a 
DLL or other type of module, wherein the external code module implements the 
functionality. 

In other embodiments, the user may specify any of various other types of 
information, e.g., to specify a file name(s) for the second graphical program, to specify 
options affecting the appearance of the user interface for the second graphical program, etc. 

As described above, the method may construct an abstract representation of the first 
graphical program and may use this representation in programmatically generating the 
second graphical program. In one embodiment, the first graphical program is abstractly 
represented as a directed graph. For example, the method may operate to construct an 
adjacency list representing one or more of data flow, control flow, and/or execution flow 
among block diagram nodes. 

In some cases, the first graphical program may utilize programming techniques not 
supported by the programming environment of the second graphical program. Thus the 
method may alter the abstract representation of the first graphical program as necessary to 
account for such differences or may take these differences into account when the second 
graphical program is generated. For example, the Simulink programming environment 
supports the use of loops among block diagram node interconnections, but the Lab VIEW 
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programming environment does not. Thus, when translating a Simulink program that 
includes such a loop to a LabVIEW program, a directed graph representation of the 
Simulink program may be created and analyzed for the existence of loops. If loops are 
detected, the loops may be removed, e.g., by using a LabVIEW local variable node to 
5 implement equivalent functionality without using a loop. 

In one embodiment, a script specifying the creation of the second graphical 
program may be automatically created, based on the abstract representation of the first 
graphical program. This script may facilitate the programmatic creation of the second 
graphical program. For example, in one embodiment the script may comprise a list of 

10 operations for creating block diagram nodes of the appropriate types and having 
appropriate sizes and positions within the block diagram, another list of operations for 
wiring the block diagram nodes together, etc. The second graphical program may then be 
programmatically generated, based on the script. For example, in one embodiment each 
operation of the script may have an equivalent application programming interface (API) 

15 call that may be executed. By executing API calls specified by the script, the second 
graphical program may be programmatically created. In another embodiment, script 
operations may not have a one-to-one correspondence with API calls, but multiple API 
calls may be performed to perform each script operation. 

As described above, the second graphical program may be associated with a second 

20 programming environment. The method may create the second graphical program in any of 
various ways. In one embodiment, the second programming environment provides an 
application programming interface (API) that may be used to programmatically create the 
second graphical program. For example, for each node, user interface element, or other 
object of the second graphical program, the API may be called to programmatically add the 

25 object to the second graphical program, connect the object to other objects of the second 
graphical program, etc. 

Depending on the functionality and implementation of the first graphical program, 
the programmatically generated second graphical program may be a fully working program 
that implements the entire functionality of the first graphical program. In this case, the user 
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can execute the second graphical program in the second programming environment, and the 
second graphical program will perform identically with or substantially like the first 
graphical program. In this case, the user can execute the second graphical program in the 
second programming environment, and the second graphical program will perform 
identically with or substantially like the first graphical program. However, in some cases, it 
may not be desirable or possible to create a fully identical and/or fully working second 
graphical program. For example, the second programming environment may not support 
certain functionality used in the first graphical program. In this case, the user may need to 
alter or complete the second graphical program before executing it. For example, the 
second programming environment may allow the user to link the second graphical program 
with an external code module which implements missing functionality. 

In various embodiments, the system and method may be utilized to port graphical 
programs from any of various first programming environments to any of various second 
programming environments. The first and second graphical programs may utilize one or 
more of data flow, control flow, and execution flow. In one embodiment, the system and 
method may be used to automatically generate a Lab VIEW program from a Simulink 
program. The Simulink programming environment is operable to create a textual "model 
file" that describes a Simulink graphical program. The method may receive this model 
file and parse the file to construct a directed graph data structure abstractly representing 
the Simulink graphical program. The method may then utilize an API supported by the 
Lab VIEW programming environment to programmatically generate a Lab VIEW program 
that implements at least a portion of the functionality of the Simulink program. 

Lab VIEW provides support to download Lab VIEW programs to hardware devices 
such as FPGA's and other programmable logic devices, e.g., for execution in an 
embedded system. Lab VIEW also provides support to download Lab VIEW programs to 
an embedded memory for execution by an embedded processor executing a real time 
operating system, thus supporting more deterministic performance. The programming 
environment of the first graphical program may not support downloading the first 
graphical program to a hardware device or may not support the desired hardware device. 
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Thus, in one embodiment, a second graphical program that is generated based on a first 
graphical program may be executed in a computing environment in which the first 
graphical program cannot execute. 
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Brief Description of the Drawings 



A better understanding of the present invention can be obtained when the 
following detailed description of the preferred embodiment is considered in conjunction 
5 with the following drawings, in which: 

Figures 1A and IB illustrate representative instrumentation and process control 
systems including various I/O interface options; 

10 Figure 2 is an exemplary block diagram of the computer systems illustrated in 

Figures 1A and IB; 

Figure 3 is a flowchart diagram illustrating one embodiment of a method for 
programmatically generating a second graphical program based on a first graphical 
15 program; 

Figure 4 is a flowchart diagram illustrating one embodiment of steps 202 and 204 
of Figure 3, in which an abstract representation of the first graphical program is 
constructed and the second graphical program is then programmatically generated based 
20 on this abstract representation; 

Figure 5 is a flowchart diagram illustrating one embodiment of step 220 of Figure 

4, in which program information for a first graphical program is analyzed in order to 
create a directed graph representation of the first program; 

25 

Figure 6 is a flowchart diagram illustrating one embodiment of step 246 of Figure 

5, in which an adjacency list specifying one or more of data flow, control flow, and/or 
execution flow for the block diagram nodes of the first graphical program is created; 
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Figure 7 illustrates an exemplary Simulink graphical program which generates and 
displays a waveform; 

Figure 8 illustrates a two-dimensional adjacency list array representing the 
Simulink program of Figure 7; 

Figure 9 illustrates an abstract directed graph equivalent to the adjacency list 
shown in Figure 8; 

Figure 10 illustrates a user interface for a graphical program generation (GPG) 
program, in which a script specifying creation of a second graphical program is displayed; 

Figure 1 1 illustrates a Lab VIEW block diagram generated based on the script of 
Figure 10, wherein the LabVIEW block diagram implements functionality of the 
Simulink block diagram of Figure 7; 

Figure 12 illustrates another view of the LabVIEW block diagram of Figure 11, in 
which a user has moved a local variable node from its default location; 

Figure 13 illustrates a user interface panel corresponding to the LabVIEW block 
diagram of Figure 11, which was automatically generated when the LabVIEW graphical 
program was programmatically generated; and 

Figures 14 - 19 illustrate portions of a graphical program generation (GPG) 
program operable to translate a Simulink graphical program to a LabVIEW graphical 
program, wherein the GPG program is itself a graphical program. 

While the invention is susceptible to various modifications and alternative forms, 
specific embodiments thereof are shown by way of example in the drawings and are 
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herein described in detail. It should be understood, however, that the drawings and 
detailed description thereto are not intended to limit the invention to the particular form 
disclosed, but on the contrary, the intention is to cover all modifications, equivalents and 
alternatives falling within the spirit and scope of the present invention as defined by the 
appended claims. 
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Detailed Description of the Preferred Embodiments 

Incorporation by Reference 

The following reference is hereby incorporated by reference in its entirety as 
5 though fully and completely set forth herein: 

U.S. Patent No. 5,481,741 titled "Method and Apparatus for Providing Attribute 
Nodes in a Graphical Data Flow Environment," issued on January 2, 1996. 

U.S. Patent Application Serial No. titled "System and Method for 

10 Programmatically Generating a Graphical Program in Response to Program Information" 
filed on December 20, 2000, whose inventors were Ram Kudukoli, Robert Dye, Paul F. 
Austin, Lothar Wenzel, and Jeffrey L. Kodosky 

U.S. Patent Application Serial No. 09/518,492 titled "System and Method for 
Programmatically Creating a Graphical Program" filed on March 3, 2000, whose 
15 inventors were Ram Kudukoli, Robert Dye, Melanie Jensen, and Yumiko Kawachi. 

U.S. Patent Application Serial No. 09/595,003 titled "System and Method for 
Automatically Generating a Graphical Program to Implement a Prototype" filed on June 
13, 2000, whose inventors were Nicolas Vazquez, Jeffrey L. Kodosky, Ram Kudukoli, 
Kevin L. Schultz, Dinesh Nair, and Christophe Caltagirone. 
20 U.S. Patent Application Serial No. 08/912,445 titled "Embedded Graphical 

Programming System" filed on August 18, 1997, whose inventors were Jeffrey L. 
Kodosky, Darshan Shah, Samson DeKey, and Steve Rogers. 

U.S. Patent Application Serial No. 08/912,427 titled "System and Method for 
Converting Graphical Programs Into Hardware Implementations" filed on August 18, 
25 1997, whose inventors were Jeffrey L. Kodosky, Hugo Andrade, Brian Keith Odom, and 
Cary Paul Butler. 

Figures 1A and IB - Instrumentation and Industrial Automation Systems 
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Graphical programs may execute on any of various types of computer systems and 
may perform or control any of various types of operations, processes, or computations. In 
one embodiment, a graphical program may be utilized to perform an instrumentation 
application, such as a test and measurement or industrial automation application. Figures 
5 1A and IB illustrate exemplary systems for performing instrumentation applications and 
automation applications. An exemplary computer 102 having various types of instruments 
or hardware devices connected is illustrated. In various embodiments, the computer 102 
may be any of various types of computer systems. 

As described below, one embodiment of the present invention comprises a system 
10 and method for programmatically generating a second graphical program based on a first 
graphical program. In Figures 1A and IB, the first graphical program and/or the second 
graphical program may execute on the computer 102. Also, the second graphical program 

O 

may be downloaded to a hardware device connected to the computer 102 and may execute 
p within the hardware device. For example, the second graphical program may be generated 

pi 15 in association with a programming development environment operable to download the 

M= second graphical program to the hardware device for execution. 

OT The first graphical program may be associated with a first programming 

^ development environment application, and the second graphical program may be associated 

: i : 

RJ with a second different programming development environment application. The 

S 20 computer-implemented method to programmatically generate the second graphical program 

^ may be implemented in either of the first or second programming development environment 

applications or may be implemented in a separate software program which executes on the 
computer 102 or another computer, such as a computer connected to the computer 102 via a 
network. 

25 It is noted that Figures 1 A and IB are exemplary, and the present invention may be 

used with any of various types of computer systems. For example, in various embodiments, 
the first graphical program, the second graphical program, and/or the software that 
programmatically generates the second graphical program may execute on any of various 
types of computer systems and for any of various applications. 
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Figure 1A illustrates an exemplary instrumentation control system 100. The system 
100 comprises a host computer 102 which connects to one or more instruments. The host 
computer 102 may comprise a CPU, a display screen, memory, and one or more input 
devices such as a mouse or keyboard as shown. The computer 102 connects through the 
5 one or more instruments to analyze, measure, or control a unit under test (UUT) or process 
150. 

The one or more instruments may include one or more of a GPIB instrument 112 
and associated GPIB interface card 122, a data acquisition board 114 and associated signal 
conditioning circuitry 124, a VXI instrument 116, a PXI instrument 118, a video device 132 

10 and associated image acquisition card 134, a motion control device 136 and associated 
motion control interface card 138, and/or one or more computer based instrument cards 142, 
among other types of devices. 

The GPIB instrument 112 may be coupled to the computer 102 via the GPIB 
interface card 122 comprised in the computer 102. In a similar manner, the video device 

15 132 may be coupled to the computer 102 via the image acquisition card 134, and the motion 
control device 136 may be coupled to the computer 102 through the motion control 
interface card 138. The data acquisition board 114 may be coupled to the computer 102, 
and may interface through signal conditioning circuitry 124 to the UUT. The signal 
conditioning circuitry 124 preferably comprises an SCXI (Signal Conditioning extensions 

20 for Instrumentation) chassis comprising one or more SCXI modules 126. 

The GPIB card 122, the image acquisition card 134, the motion control interface 
card 138, and the DAQ card 1 14 are typically plugged in to an I/O slot in the computer 102, 
such as a PCI bus slot, a PC Card slot, or an ISA, EISA or MicroChannel bus slot provided 
by the computer 102. However, these cards 122, 134, 138 and 114 are shown external to 

25 computer 102 for illustrative purposes. 

The VXI chassis or instrument 116 may be coupled to the computer 102 via a VXI 
bus, MXI (e.g., MXI-3) bus, or other serial or parallel bus provided by the computer 102. 
The computer 102 preferably includes VXI interface logic, such as a VXI, MXI or GPIB 
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interface card (not shown), which interfaces to the VXI chassis 116. The PXI chassis or 
instrument is preferably coupled to the computer 102 through the computer's PCI bus. 

A serial instrument (not shown) may also be coupled to the computer 102 through a 
serial port, such as an RS-232 port, USB (Universal Serial bus) or IEEE 1394 or 1394.2 
5 bus, provided by the computer 102. 

In typical instrumentation control systems an instrument will not be present of each 
interface type, and in fact many systems may only have one or more instruments of a single 
interface type, such as only GPIB instruments. The one or more instruments are coupled to 
the unit under test (UUT) or process 150, or are coupled to receive field signals, typically 
10 generated by transducers. The system 100 may be used in a data acquisition and control 
application, in a test and measurement application, a process control application, or a man- 
machine interface application. 

Figure IB illustrates an exemplary industrial automation system 160. The industrial 
15 automation system 160 is similar to the instrumentation or test and measurement system 
100 shown in Figure 1A. Elements which are similar or identical to elements in Figure 1 A 
have the same reference numerals for convenience. The system 160 may comprise a 
computer 102 which connects to one or more devices or instruments. The computer 102 
may comprise a CPU, a display screen, memory, and one or more input devices such as a 
20 mouse or keyboard as shown. The computer 102 may connect through the one or more 
devices to a process or device 150 to perform an automation function, such as MMI (Man 
Machine Interface), SCADA (Supervisory Control and Data Acquisition), portable or 
distributed data acquisition, process control, advanced analysis, or other control. 

The one or more devices may include a data acquisition board 1 14 and associated 
25 signal conditioning circuitry 124, a PXI instrument 118, a video device 132 and associated 
image acquisition card 134, a motion control device 136 and associated motion control 
interface card 138, a fieldbus device 170 and associated fieldbus interface card 172, a PLC 
(Programmable Logic Controller) 176, a serial instrument 182 and associated serial 
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interface card 184, or a distributed data acquisition system, such as the Fieldpoint system 
available from National Instruments, among other types of devices. 

The DAQ card 114, the PXI chassis 118, the video device 132, and the image 
acquisition card 136 are preferably connected to the computer 102 as described above. The 

5 serial instrument 182 is coupled to the computer 102 through a serial interface card 184, or 
through a serial port, such as an RS-232 port, USB, or IEEE 1394 or 1394.2 provided by the 
computer 102. The PLC 176 couples to the computer 102 through a serial port, Ethernet 
port, or a proprietary interface. The fieldbus interface card 172 is preferably comprised in 
the computer 102 and interfaces through a fieldbus network to one or more fieldbus devices. 

10 Each of the DAQ card 114, the serial card 184, the fieldbus card 172, the image acquisition 
card 134, and the motion control card 138 are typically plugged in to an I/O slot in the 
computer 102 as described above. However, these cards 114, 184, 172, 134, and 138 are 
shown external to computer 102 for illustrative purposes. In typical industrial automation 
systems a device will not be present of each interface type, and in fact many systems may 

15 only have one or more devices of a single interface type, such as only PLCs. The devices 
are coupled to the device or process 150. 

Referring again to Figures 1A and IB, the computer system(s) 102 preferably 
includes a memory medium(s) on which software according to one embodiment of the 

20 present invention is stored. For example, the memory medium may store a first graphical 
program created in a first graphical programming development environment. The memory 
medium may also store a program, also referred to herein as a "graphical program 
generation (GPG) program" that is executable to programmatically generate a second 
graphical program based on the first graphical program. The same or a different memory 

25 medium may also store a second graphical programming development environment 
application, e.g., to execute or edit the second graphical program. It is noted that various of 
these software programs may be stored on different computer systems. 

The term "memory medium" is intended to include an installation medium, e.g., a 
CD-ROM, floppy disks 104, or tape device, a computer system memory or random access 
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memory such as DRAM, SRAM, EDO RAM, Rambus RAM, etc., or a non-volatile 
memory such as a magnetic media, e.g., a hard drive, or optical storage. The memory 
medium may comprise other types of memory as well, or combinations thereof. 

In addition, the memory medium may be located in a first computer in which the 
programs are executed, or may be located in a second different computer which connects to 
the first computer over a network, such as the Internet. In the latter instance, the second 
computer provides the program instructions to the first computer for execution. Also, the 
computer system 102 may take various forms, including a personal computer system, 
mainframe computer system, workstation, network appliance, Internet appliance, personal 
digital assistant (PDA), television system, programmable logic device, or other device. In 
general, the term "computer system" can be broadly defined to encompass any device 
having at least one processor that executes instructions from a memory medium. 

Figure 2 - Computer System Block Diagram 

Figure 2 is an exemplary block diagram of the computer systems illustrated in 
Figures 1A and IB. It is noted that any type of computer system configuration or 
architecture can be used as desired, and Figure 2 illustrates a representative PC 
embodiment. It is also noted that the computer system may be a general purpose computer 
system as shown in Figures 1 A and IB, a computer implemented on a VXI card installed in 
a VXI chassis, a computer implemented on a PXI card installed in a PXI chassis, or other 
types of embodiments. The elements of a computer not necessary to understand the 
present invention have been omitted for simplicity. 

The computer 102 includes at least one central processing unit or CPU 160 which 
is coupled to a processor or host bus 162. The CPU 160 may be any of various types, 
including an x86 processor, e.g., a Pentium class, a PowerPC processor, a CPU from the 
SPARC family of RISC processors, as well as others. Main memory 166 is coupled to 
the host bus 162 by means of memory controller 164. 

The main memory 166 may store software according to one embodiment of the 
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present invention. The main memory 166 also stores operating system software as well 
as the software for operation of the computer system, as well known to those skilled in 
the art. The methods performed by the computer programs of the present invention will 
be discussed in more detail below. 

The host bus 162 is coupled to an expansion or input/output bus 170 by means of 
a bus controller 168 or bus bridge logic. The expansion bus 170 is preferably the PCI 
(Peripheral Component Interconnect) expansion bus, although other bus types can be 
used. The expansion bus 170 includes slots for various devices such as the data 
acquisition board 114 (of Figure 1A) and a GPIB interface card 122 which provides a 
GPIB bus interface to the GPIB instrument 112 (of Figure 1A). The computer 102 further 
comprises a video display subsystem 180 and hard drive 182 coupled to the expansion 
bus 170. 

As shown, a reconfigurable instrument 190 may also be connected to the 
computer 102. The reconfigurable instrument 190 may include configurable logic, such 
as a programmable logic device (PLD), e.g., an FPGA, or a processor and memory, which 
may execute a real time operating system. According to one embodiment of the 
invention, a second graphical program programmatically generated based on a first 
graphical program may be downloaded and executed on the reconfigurable instrument 
190. For example, the graphical programming development environment with which the 
second graphical program is associated may provide support for downloading a graphical 
program for execution on configurable logic in a real time system. In various 
embodiments, the configurable logic may be comprised on an instrument or device 
connected to the computer through means other than an expansion slot, e.g., the 
instrument or device may be connected via an IEEE 1394 bus, USB, or other type of port. 
Also, the configurable logic may be comprised on a device such as the data acquisition 
board 114 or another device shown in Figure 1A. 



Figure 3 - Programmatic Generation of a Second Graphical Program 
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Figure 3 is a flowchart diagram illustrating one embodiment of a method for 
programmatically generating a second graphical program based on a first graphical 
program. 

In step 200, information specifying the first graphical program may be received. 
The first graphical program may be associated with a first programming development 
environment. For example, a user may have interactively or manually created the first 
graphical program from within the first programming development environment, e.g., by 
using an editor to place various nodes on a block diagram, such that the nodes visually 
indicate functionality of the first graphical program. The nodes may be interconnected so as 
to specify data flow, control flow, and/or execution flow among the nodes in the program. 
The nodes may also be connected in a "signal flow" format, wherein signal flow is 
considered a subset of data flow. The first graphical program may also have been 
programmatically created. 

During creation of the first graphical program, the first programming development 
environment may create one or more files which specify the first graphical program. In 
various embodiments, these files may comprise text and/or binary information. The 
information received in step 200 may include information from one or more of these files. 
For example, the information may include information specifying a set of nodes that the 
first graphical program uses, interconnections among these nodes, programmatic structures 
such as loops, etc. The information may also include information specifying a user interface 
for the first graphical program. 

In various embodiments, the information specifying the first graphical program may 
be received in any of various formats or file types, e.g., depending on the first programming 
development environment used to create the first graphical program. For example, the 
information may include information received from one or more binary files specifying 
various data structures which the first programming development environment creates in 
response to development of the first graphical program and which the first programming 
development environment uses to directly represent the program. 
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In another embodiment, the information received in step 200 may include abstract 
information describing the first graphical program, e.g., abstract information stored in a text 
file which the first programming development environment is operable to generate. For 
example, such abstract information may fully specify the first graphical program, but the 
5 first programming development environment may also maintain other files, e.g., files 
including the data structures described above, which allow the first programming 
development environment to more efficiently manipulate the first graphical program, e.g., 
when editing or compiling the program. An example of abstract information received in 
step 200 is described below for an embodiment in which the first graphical program is a 

10 Simulink graphical program. In this case, the information is received from a textual "model 
file" that describes the Simulink program, which the Simulink programming development 
environment is operable to create. 

In step 202, the method may programmatically analyze the information received in 
step 200 and programmatically construct an abstract representation of the first graphical 

15 program, based on this information. The information may be analyzed, examined, 
traversed, or parsed in any of various ways, e.g., depending on the particular form in which 
the information is received. An exemplary process of analyzing program information for 
the first graphical program is described below. As the information is analyzed, the method 
may operate to construct a data structure or set of data structures that abstractly represent the 

20 first graphical program. In various embodiments, the first graphical program may be 
abstractly represented in any of various ways. An embodiment in which the first graphical 
program is represented as a directed graph is described below. 

In step 204, the second graphical program may be programmatically generated, 
based on the abstract representation of the first graphical program constructed in step 202. 

25 Programmatically generating the second graphical program may comprise programmatically 
generating a block diagram including interconnected block diagram nodes that implement 
functionality of the first graphical program, such that when executed, the second graphical 
program performs the same as or substantially like the first graphical program. 
Programmatically generating the second graphical program may also comprise 
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programmatically creating a graphical user interface for the second graphical program, such 
that when the second graphical program is executed, the graphical user interface enables the 
second graphical program to receive user input and/or display output similarly as the first 
graphical program. 

5 The method may generate the second graphical program programmatically, without 

relying on user input, or may prompt for a small amount of user input to determine various 
options to use in generating the second graphical program. For example, in various 
embodiments the user may specify options such as whether to generate the second graphical 
program so that it resembles the first graphical program as closely as possible, e.g., in the 

10 layout and interconnections among block diagram nodes, or whether to perform 
optimizations or modifications where possible or necessary, e.g., to facilitate downloading 
the second graphical program to a hardware device for execution. 

The user may also be prompted for information enabling various aspects of the first 
graphical program to be translated. For example, in one embodiment, the first graphical 

15 program may include functionality not natively supported by the programming development 
environment of the second graphical program or may include functionality for which the 
method lacks the necessary knowledge to translate. Thus, the user may be prompted to 
specify equivalent functionality to be included in the second graphical program, e.g., by 
specifying one or more nodes supported by the second graphical program's programming 

20 development environment or by specifying an external code module with which the second 
graphical program can interface, such as a DLL or other type of module, wherein the 
external code module implements the functionality. 

In other embodiments, the user may specify any of various other types of 
information, e.g., to specify a file name(s) for the second graphical program, to specify 

25 options affecting the appearance of the user interface for the second graphical program, etc. 

The second graphical program may be generated in such a way as to be associated 
with a second programming development environment. For example, as described above, a 
programming development environment may use any of various types of files to specify a 
graphical program, such as text or binary files that specify a set of nodes that the graphical 
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program uses, interconnections among these nodes, programmatic structures such as loops, 
etc. Thus, in step 204 a file or set of files may be created of the appropriate format such that 
the second programming development environment is operable to treat the generated second 
graphical program as if the second graphical program were interactively created by a user 
from within the second programming development environment. Thus, once the second 
graphical program has been generated, the user may use the second programming 
development environment to edit the second graphical program, execute the second 
graphical program, etc. 

In the preferred embodiment, the second programming development environment 
provides an application programming interface (API) that may be used to programmatically 
create the second graphical program. For example, for each node, user interface element, or 
other object of the second graphical program, the API may be called to programmatically 
add the object to the second graphical program, connect the object to other objects of the 
second graphical program, etc. Thus, any necessary files or other constructs needed by the 
second programming development environment in order to use the second graphical 
program may be automatically created as a result of calling the API. In another 
embodiment, the method may operate to directly create these files, rather than calling an 
API to do so. 

Depending on the functionality and implementation of the first graphical program, 
the programmatically generated second graphical program may be a fully working program 
that implements the entire functionality of the first graphical program. In this case, the user 
can execute the second graphical program in the second programming development 
environment, and the second graphical program will perform identically with or 
substantially like the first graphical program. However, in some cases, it may not be 
possible to create a fully working second graphical program. For example, the second 
programming development environment may not support certain functionality used in the 
first graphical program. In this case, the user may need to alter or complete the second 
graphical program before executing it. For example, the second programming development 
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environment may allow the user to link the second graphical program with an external code 
module which implements missing functionality. 



HI 



In the description above, the abstract representation created in step 202 is described 
5 as a representation of the first graphical program, which is then used in programmatically 
generating the second graphical program. It is noted that in various embodiments, it may be 
more accurate to describe the abstract representation as a representation of the functionality 
of the first (and/or second) graphical program. For example, in some embodiments, the 
second programming development environment of the second graphical program may not 

10 support a one-to-one translation of nodes of the first graphical program into nodes for the 
second graphical program, e.g., because one or more nodes of the first program are not 
supported by the second programming development environment. 

Thus, in various embodiments, the abstract representation may be modified in such 
a way that a second graphical program supported by the second programming development 

15 environment may be generated from the abstract representation. Such modifications may be 
performed in any way appropriate for a particular embodiment or program. For example, in 
the situation described above in which a first node of the first program does not have an 
equivalent node in the second programming development environment, it may be possible 
to modify the abstract information to substitute two or more interconnected nodes 

20 performing equivalent functionality of the first node, such that when the second graphical 
program is programmatically generated based on the abstract information, the two or more 
interconnected nodes are included in the block diagram of the second graphical program. In 
another embodiment, the abstract representation may not be modified, but the multiple 
nodes may be substituted for the first node at the time that the second graphical program is 

25 programmatically generated from the abstract information. 

As another example, the abstract representation may be modified to account for 
programming models or techniques used in the first graphical program but not supported by 
the second programming development environment. For example, as described below, in 
one embodiment the first graphical program may have one or more loops among block 



Atty. Dkt. No.: 5150-48000 



Page 27 



Conley, Rose & Tayon, P.C. 



diagram nodes, but the second programming development environment may not support 
such loops. When first constructed, the abstract representation may reflect the use of such a 
loop in the first graphical program. Thus, the abstract representation may need to be 
modified such that features supported by the second programming development 
5 environment are used to represent an equivalent program that does not utilize loops among 
block diagram nodes. 

As another example, the abstract representation may be modified, if desired by the 
user, to improve program efficiency, e.g., to facilitate downloading the second graphical 
program to a hardware device for execution. For example, in some cases it may be possible 

10 to automatically reorder various block diagram nodes, e.g., to achieve increased parallelism 
during program execution. 

Thus in various embodiments, the final abstract representation used to create the 
second graphical program in step 204 may be constructed in various ways and/or in multiple 
steps, and the final abstract representation may or may not closely resemble the first 

15 graphical program, e.g., in terms of interconnected nodes specified by the abstract 
representation. In the preferred embodiment, the final abstract representation is, however, 
faithful to the first graphical program in terms of functionality of the first graphical 
program, at least so far as possible. 

20 

Figure 4 - Steps 202 and 204 

Figure 4 is a flowchart diagram illustrating one embodiment of steps 202 and 204 
of Figure 3, in which an abstract representation of the first graphical program is 
constructed and the second graphical program is then programmatically generated based 
25 on this abstract representation. As described above, the first program may be represented 
in any of various ways. In the embodiment shown in Figure 4, program information for 
the first program may be analyzed in order to represent the first program as a directed 
graph, a well-known data structure in the art. 
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In step 220, program information for the first graphical program may be analyzed 
in order to create the directed graph representation. One embodiment of step 220 is 
described below. 

In step 222, the method may analyze the directed graph representation to detect 
5 loops in the graph and may alter the representation in order to remove the loops. Step 
222 may be performed in a case when the programming development environment of the 
first graphical program supports loops in the interconnections among block diagram 
nodes, but the programming development environment of the second graphical program 
does not. In other cases, step 222 may not be necessary. The directed graph may be 

10 modified in any of various ways, e.g., depending on the second programming 
development environment, such that the loop(s) is removed, and the second graphical 
program still functions equivalently to the first graphical program. One example of 
modifying the directed graph to account for loops is described below. 

In step 224, a script specifying the creation of the second graphical program may 

15 be created, based on the directed graph representation. This script may facilitate the 
programmatic creation of the second graphical program. For example, in one 
embodiment the script may comprise a list of operations to create block diagram nodes of 
the appropriate types and having appropriate sizes and positions within the block 
diagram, another list of operations to wire the block diagram nodes together, etc. 

20 In step 226, the second graphical program may then be programmatically 

generated, based on the script. For example, in one embodiment each operation of the 
script may have an equivalent application programming interface (API) call that may be 
executed. By executing API calls specified by the script, the second graphical program 
may be programmatically created. In another embodiment, script operations may not 

25 have a one-to-one correspondence with API calls, but multiple API calls may be 
performed to perform each operation. 

It is noted that some embodiments may not use a script, and thus step 224 may not 
be performed. For example, instead of first determining a list of operations that will 
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result in the desired second graphical program being generated and then performing the 
operations, each operation may be performed as the operation is determined. 

As described above, the directed graph representation of the first graphical 
program may be altered after first being constructed. Thus, in various embodiments the 
5 first graphical program may initially be represented as a directed graph, but the final 
information used in creating the script in step 224 may or may not be a directed graph 
representation. 



10 Figure 5 - Creating a Directed Graph Representation of a First Graphical Program 

Figure 5 is a flowchart diagram illustrating one embodiment of step 220 of Figure 
4, in which program information for a first graphical program is analyzed in order to 
create a directed graph representation of the first program. 

In step 240, an array or list of block diagram nodes included in the first graphical 

15 program may be created. These block diagram nodes may be determined in any of 
various ways, e.g., depending on the format or content of the program information being 
analyzed. As described above, the program information for the first graphical program 
may comprise the first graphical program itself, i.e., one or more files or data structures 
specifying the first graphical program, or may comprise abstract information specifying 

20 the first graphical program, such as a textual model file. The program information is 
preferably structured or organized in a known manner, making possible the determination 
of the block diagram nodes comprised in the block diagram of the first graphical program. 

In step 242, an array or list of lines may be created, wherein each line connects a 
block diagram source node to a block diagram destination node. Thus, the array of lines 

25 represents the interconnections among block diagram nodes, wherein each 
interconnection may represent one or more of a directional data flow, control flow, and/or 
execution flow from a source node to a destination node. Similarly, as for step 240, the 
lines included in the first graphical program may be determined in any of various ways, 
depending on the format or content of the program information being analyzed. 
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In step 244, coordinate bounds and origins related to user interface panel(s) (or 
windows) and block diagram panel(s) (or windows) of the first graphical program may be 
determined and recorded. It may be desirable for the second graphical program to 
resemble the first graphical program as closely as possible. Thus, by determining 
coordinate origins and sizes of panels of the first graphical program and by determining 
origins and sizes of objects within these windows, windows of the second graphical 
program may be created of the appropriate size and at the appropriate positions, and 
objects may be created of the appropriate sizes and arranged properly within the windows 
of the second graphical program. 

Step 244 may apply to user interface panels or windows of the first graphical 
program. For each user interface panel, the size and origin of the panel may be 
determined. Similarly as described above, the program information of the first graphical 
program preferably enables the method to determine this information, and the information 
may be determined in any of various ways. Also, for each user interface element, such as 
user interface controls and indicators, the size of the element and the origin of the element 
within the user interface panel may be determined and recorded, so that the appearance of 
the user interface may be duplicated for the second graphical program. 

Step 244 may also apply to block diagram panels or windows of the first graphical 
program. For each block diagram panel, the size and origin of the panel may be 
determined. Similarly as described above, the program information of the first graphical 
program preferably enables the method to determine this information, and the information 
may be determined in any of various ways. Thus, the block diagram panels of the second 
graphical program may be sized and arranged similarly as in the first graphical program, 
e.g., when the block diagram panels are displayed at edit time. Also, for each block 
diagram node or other object within a block diagram, the size of the object and the origin 
of the object within the block diagram panel may be determined and recorded, so that the 
appearance of the block diagram may be duplicated for the second graphical program. 

In step 246, an adjacency list specifying one or more of data flow, control flow, 
and/or execution flow for the block diagram nodes of the first graphical program may be 
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created. This adjacency list may be equivalent to a directed graph data structure 
representing the first graphical program, wherein each block diagram node has an 
equivalent node in the directed graph, and each line connecting two block diagram nodes 
is represented as an edge in the directed graph. The adjacency list may be determined and 
represented in any of various ways. One embodiment of a method for determining the 
adjacency list is described below. 

Once the adjacency list has been created, the second graphical program may be 
programmatically created from the adjacency list information, as described above (and 
possibly after making modifications to the information, as described). 

Figure 6 - Creating the Adjacency List 

Figure 6 is a flowchart diagram illustrating one embodiment of step 246 of Figure 
5, in which an adjacency list specifying one or more of data flow, control flow, and/or 
execution flow for the block diagram nodes of the first graphical program is created. In 
this embodiment, a two-dimensional array representing the adjacency list is created. 

The flowchart of Figure 6 illustrates two nested loops. The outer loop is 
performed for each node in the array of block diagram nodes, and the inner loop is 
performed for each line in the array of lines and during each iteration of this outer loop. 

In step 300, given a current block diagram node (with respect to the outer loop) 
and current line (with respect to the inner loop), the method determines whether the 
current block diagram node is the same as the source node for the line. If so, then in step 
302 the destination node for the line is added to a one-dimensional array associated with 
the current block diagram node. 

Thus, once step 300 has been performed for each line, a one-dimensional array for 
the current block diagram node will have been created, wherein the array includes each 
destination node for which the current node is a source. In step 306, this one-dimensional 
array may be added as a row in a two-dimensional array. Thus, once the outer loop has 
been performed for each block diagram node, the two-dimensional array includes a row 
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associated with each block diagram node, wherein each row specifies zero or more 
destination nodes for which the block diagram node is a source. As illustrated in an 
example below, this two-dimensional array is equivalent to a directed graph 
representation of the first graphical program. 

As noted above, Figure 6 represents one embodiment of creating an adjacency list, 
and any of various other methods may be used. Also, other equivalent or similar 
representations may be used in place of this type of adjacency list. For example, in one 
embodiment, an equivalent structure referred to as an adjacency matrix may be created 
instead of or in addition to an adjacency list. Given a graphical program with N nodes, an 
adjacency matrix may be represented as a two-dimensional array of size N*N. For an 
element [X,Y] of this array, the element would have a value of 1 if there is a line from 
block diagram node X to block diagram node Y, or would have a value of 0 otherwise. 

Figures 7-13: Simulink to Lab VIEW Example 

In various embodiments, the methods described above may be utilized to port 
graphical programs from any of various first programming development environments to 
any of various second programming development environments. Examples include: 
Simulink to LabVIEW, VEE to Lab VIEW, Softwire to Lab VIEW, Lab VIEW to 
Simulink, LabVIEW to VEE, Simulink to VEE, etc. 

In one embodiment, the method may be used to automatically generate a 
LabVIEW program from a Simulink program. The Simulink programming development 
environment is operable to create a textual "model file" that describes a Simulink 
graphical program. The method may receive this model file and parse the file to construct 
a directed graph data structure abstractly representing the Simulink graphical program. 
The method may then utilize an API supported by the LabVIEW programming 
development environment to programmatically generate a LabVIEW program that 
implements functionality of the Simulink program. 
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Figure 7 illustrates an exemplary Simulink graphical program which generates and 
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displays a waveform. The following text is taken from a model (.mdl) file describing the 
Simulink program, which was generated by the Simulink programming development 



environment: 
Model { 

Name "loop" 
Version 3.00 
SimParamPage " Solver" 

SampleTimeColors off 
InvariantConstants off 



0.0' 
10. ( 

ode45' 
le-3" 
auto" 
1" 

auto" 
auto" 



WideVectorLines off 
ShowLineWidths off 
ShowPortDataTypes 
StartTime 
StopTime 
SolverMode 
Solver 
RelTol 
AbsTol 
Refine 
Max Step 
InitialStep 
FixedStep 

MaxOrder 5 
OutputOption 
OutputTimes 
LoadExternallnput 
Externallnput 
SaveTime on 
TimeSaveName 
SaveState off 
States a veName 
SaveOutput 
OutputSa veName "yout 1 
LoadlnitialState 
InitialState 
SaveFinalState 
Final StateName 
SaveFormat 
LimitMaxRows 
Max Rows 
Decimation 
AlgebraicLoopMsg 
MinStepSizeMsg 
UnconnectedlnputMsg 
UnconnectedOutputMsg 



off 



"Auto" 



" auto" 



" Ref ineOutputTimes " 

"[]" 

off 

" [t, u] " 

"tout" 

"xout" 
on 



off 

"xlnitial" 

off 

"xFinal" 

" Matrix" 
off 

"1000 n 

H ^ ii 

" warning" 
"warning" 

"warning" 
"warning" 



UnconnectedLineMsg "warning" 

InheritedTsInSrcMsg "warning" 

IntegerOverf lowMsg "warning" 
UnnecessaryDatatypeConvMsg " none " 

Int32ToFloatConvMsg "warning" 

SignalLabelMismatchMsg "none" 

ConsistencyChecking "off" 
ZeroCross on 
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SimulationMode "normal" 

BlockDataTips on 

BlockParametersDataTip on 

BlockAttributesDataTip off 
5 BlockPortWidthsDataTip off 

BlockDescriptionStringDataTip off 

BlockMaskParametersDataTip off 

ToolBar on 

StatusBar on 
10 Browser ShowLibraryL inks off 

BrowserLookUnderMasks off 

OptimizeBlocklOStorage on 

BufferReuse on 

BooleanDataType off 
15 RTWSystemTargetFile "grt.tlc" 

RTWInline Parameters off 

RTWRetainRTWFile off 

RTWTemp 1 a t eMake file " g r t _de f au 1 t_t m f " 

RTWMakeC ommand " make_r t w " 
20 RTWGenerateCodeOnly off 

ExtModeMexFile "ext_comm" 

ExtModeBatchMode off 

ExtModeTrigType "manual" 
f=i ExtModeTrigMode " oneshot " 

^ 25 ExtModeTrigPort "1" 

ExtModeTrigElement "any" 

ExtModeTrigDuration 1000 
=P ExtModeTrigHoldOf f 0 

ry ExtModeTrigDelay 0 

in 30 ExtModeTrigDirection "rising" 

^ ExtModeTrigLevel 0 

L=. ExtModeArchiveMode "off" 

ExtModeAutoIncOneShot off 
E ExtModelncDirWhenArm off 

35 ExtModeAddSuff ixToVar off 

ry ExtModeWriteAllDataToWs off 

HI ExtModeArmWhenConnect off 

lr Created "Fri Aug 11 14:43:19 2000" 

UpdateHi story "UpdateHistoryNever " 

□ 40 Modif iedByFormat "%<Auto>" 

p Modif iedDateFormat "%<Auto>" 

LastModif iedDate "Fri Sep 08 17:59:07 2000" 

ModelVersionFormat " 1 . %<Au to Increment : 5> " 

Conf igurationManager "none" 
45 BlockDefaults { 

Orientation "right" 
ForegroundColor "black" 
BackgroundColor "white" 
Dr opShadow off 
50 NamePlacement "normal" 

FontName "Helvetica" 
FontSize 10 
FontWeight "normal" 
FontAngle "normal " 

55 ShowName on 

} 

Anno t a t i onDe f au 1 1 s { 

HorizontalAlignment "center" 
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VerticalAlignment 

ForegroundColor 

BackgroundColor 

DropShadow 

Font Name 

FontSize 

FontWeight 

FontAngle 



} 

LineDef aults 
FontName 
FontSize 
FontWeight 
FontAngle 

} 

System { 
Name 

Location 
Open 



{ 



"middle" 
"black" 
"white" 
off 

"Helvetica" 
10 

"normal" 
"normal" 



" Helvetica" 
9 

"normal" 
" normal" 



•loop" 



on 



ModelBrowserVisibility 
ModelBrowserWidth 
ScreenColor 
PaperOrientation 
Pape r Po s i t i onMode 
PaperType 
PaperUnits 
ZoomFactor 
AutoZoom 
ReportName 
Block { 

BlockType 

Name 

Position 

} 

Block { 

BlockType 
Name 
Ports 
Position 
Orientation 
ExternalReset 
InitialConditionSource 
InitialCondition 
LimitOutput off 
UpperSaturationLimit 
LowerSaturationLimit 
ShowSaturationPort 
ShowStatePort 
AbsoluteTolerance 

} 

Block { 

BlockType 
Name 
Ports 
Position 
Floating 
Location 
Open 



[328, 77, 828, 378] 

off 
200 

" automatic" 
" landscape" 
" auto" 
"usletter" 
" inches" 
"100" 
on 

" simulink-def ault . rpt " 



Derivative 
"Derivative" 

[230, 85, 260, 115] 



Integrator 
"Integratorl" 
[1, 1, 0, 0, 0] 
[240, 161, 

"left" 



270, 199] 



11 none " 

" internal ' 
ii 2_ " 

"inf " 
"-inf " 
off 
off 
"auto" 



Scope 
" Scope " 

[1, 0, 0, 0, 0] 
[335, 84, 
off 

[389, 458, 

off 



365, 116] 
713, 697] 
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Numlnput Ports 

TickLabels 

ZoomMode 

List { 

ListType 

axesl 

} 

Grid 

TimeRange 

YMin 

YMax 

SaveToWorkspace 

SaveName 

DataFormat 

LimitMaxRows 

MaxRows 

Decimation 

Samplelnput 

SampleTime 

} 

Block { 

BlockType 
Name 
Position 
Amplitude 
Frequency- 
Phase 

SampleTime 

} 

Block { 
BlockType 
Name 
Ports 
Position 
ShowName 
IconShape 
Inputs 



" OneTimeTick" 
"on" 

AxesTitles 
"%<SignalLabel>" 

" on " 

" auto" 

n ^ ii 

off 

"ScopeData" 
" StructureWithTime " 
on 

"5000" 

"1" 
off 
»0" 



Sin 
'Sine Wave" 

[115, 85, 145, 115] 



Sum 

" Sum" 

[2, 1, 0, 0, 0] 

[175, 90, 195, 110] 
off 

" round" 
»!+-■ 



SaturateOnlntegerOverf low 



on 



} 

Line { 
SrcBlock 
SrcPort 
Points 
Branch { 
DstBlock 
DstPort 
} 

Branch { 

Points 

DstBlock 

DstPort 

} 

} 

Line { 
SrcBlock 
SrcPort 
DstBlock 
DstPort 



"Derivative " 
1 

[30, 



0] 



■Scope" 
1 



[0, 80] 
•Integratorl" 
1 



"Sum" 
1 

"Derivative " 
1 
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} 

Line { 

SrcBlock "Sine Wave" 

SrcPort 1 
5 DstBlock "Sum" 

DstPort 1 

} 

Line { 

SrcBlock " Integratorl " 

10 SrcPort 1 

Points [-50, 0] 

DstBlock "Sum" 
DstPort 2 

} 

15 } 



The method may receive this model file description of the Simulink graphical 

20 program and analyze this information to construct an abstract representation of the 

^ Simulink graphical program. As described above, in one embodiment the Simulink 

yg graphical program may be represented as a directed graph, which may be constructed as 

j= described in Figures 5 and 6. 

!if Figure 8 illustrates a two-dimensional adjacency list array computed according to 

Ui 

M> 25 the method of Figure 6. As shown, the two-dimensional array includes a row for each 

™ block diagram node of the Figure 7 Simulink graphical program (the first column 

U' r indicates the node with which the row is associated.) For each row, the columns after the 

iy 

[U first column list any destination nodes for which the node listed in the first column is a 

s 5 

p source node. Thus, for example, the "Sum" node is listed as a destination node of the 

30 "Sine Wave" source node. Note that the "Derivative" block diagram node has lines to 
both the "Scope" node and the "Integratorl" node in the Figure 7 block diagram. Thus, 
the adjacency list indicates that both the "Scope" node and the "Intergratorl" node are 
destination nodes for the "Derivative" node. Since the "Scope" node is a pure sink, no 
destination nodes for the "Scope" node are indicated in the adjacency list. Figure 9 
35 illustrates an abstract directed graph equivalent to the adjacency list shown in Figure 8. 
Note that the abstract directed graph of Figure 9 appears very similar to the actual 
graphical program block diagram of Figure 7. 
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In the description above, it is assumed that a single output signal is associated 
with each block diagram node. In many graphical programming development 
environments, such as Lab VIEW, block diagram nodes may have multiple input and/or 
output terminals. For programs having nodes which receive and/or provide multiple 

5 signals using different node terminals, the method described above may be modified to 
account for the multiple terminals, e.g., by subindexing the terminals. Thus, instead of 
the adjacency list having one row for each block diagram node, there may be multiple 
rows for each node, depending on the number of output terminals for the node. Also, 
each destination node may be listed according to which input terminal of the destination 

10 node receives the signal. 



& As shown in the block diagram of Figure 7 and the abstract directed graph of 

yB Figure 9, the first graphical program has a loop among the interconnections of the "Sum", 

j= "Derivative", and "Integratorl" block diagram nodes. The LabVTEW programming 

j*j 15 development environment does not support the use of these types of block diagram loops. 

M 8 Thus, as illustrated in step 222 of Figure 4, the directed graph representation of the 

Q 

f~ Simulink graphical program may be analyzed in order to detect and remove such loops. 

JT7 Techniques for detecting loops in directed graphs are well known in the art and are not 

[U described herein. Once a loop has been detected, the abstract representation of the first 

□ 20 graphical program may be modified in any of various ways, depending on a particular 

~ embodiment (or, as discussed above, the abstract information may not be modified, but 

the loop may be taken into account when the second graphical program is generated). 

For the LabVEW programming development environment, the LabVDEW 
graphical program may be generated to utilize a Lab VIEW local variable node, avoiding 
25 the use of a loop. Figure 12 illustrates the block diagram of a LabVTEW graphical 
program programmatically generated based on the Simulink program shown in Figure 7. 
As shown, the LabVIEW block diagram includes a local variable node labeled 
"Integratorl". This local variable is logically associated with the output value of the 
"Integratorl" block diagram node, such that the output value and the value of the local 
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variable node are always the same. Since the local variable node is a source node for the 
"Sum" node, the effect is the same as if the "Integrator 1" node output looped back to the 
"Sum" node. 

As described above with reference to Figure 4, in one embodiment a script 
specifying the creation of the second graphical program may be created, based on the 
abstract representation of the first graphical program, and this script may be used in 
programmatically generating the second graphical program. Figure 10 illustrates a user 
interface for a graphical program generation (GPG) program, displaying such a script, and 
Figure 11 illustrates a Lab VIEW block diagram generated based on the script. As shown, 
the script includes a set of CREATE operations specifying block diagram nodes to be 
created. 

For each CREATE operation, the GPG program may include one or more nodes 
in the second graphical program, based on the node to be created. In one embodiment, 
each node listed in a CREATE script operation may have one corresponding node 
provided by the programming development environment of the second graphical 
program, and this corresponding node may thus be included in the second graphical 
program. As shown, the CREATE operations may specify the desired coordinate origin 
and/or size for each node. 

In another embodiment, the GPG program may include multiple block diagram 
nodes in the second graphical program's block diagram and may wire them together 
appropriately in order to implement the node specified by a CREATE operation. If 
desired, the GPG program may encapsulate these multiple nodes behind a single 
subprogram node, such that the top-level block diagram of the second graphical program 
appears the same as the first graphical program. 

In various embodiments, implementing a CREATE operation may involve not 
only including one or more nodes in the second graphical program, but also properly 
configuring the nodes. For example, the GPG program may set various properties 
associated with each node to perform this configuration. Also, the configuration may 
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involve adding additional elements to the block diagram. For example, as shown in the 
Lab VIEW program of Figure 11, numeric or other constant values may need to be wired 
to the nodes, wherein these values may affect the execution of a node. Although the 
Figure 7 Simulink program does not show such values, the values may be implicitly 

5 associated with the Simulink nodes. For example, in Simulink, a user may double-click 
on a Simulink node to display a dialog box for setting the values affecting various node 
properties. On the other hand, in Lab VIEW the values may be explicitly shown as node 
inputs in the block diagram. 

In one embodiment, the GPG program may utilize translation information from an 

10 external file or database, wherein the translation information specifies how to implement 
CREATE operations. For example, the following translation information may be used in 
translating the Simulink program of Figure 7 to the Lab VIEW program of Figure 11: 



2f Block Specifications 

J! 15 Sin : SubVI ; INl : ; OUTl : sine wave ; #0 ; 

IU RandomNumber : SubVI ; INl : ; OUTl : Gaussian white noise;#0; 

Lq Integrator : SubVI ; INl : input data; OUTl : integral x(t);#l; 

|V Derivative: SubVI; INl: input data; OUTl : dx/dt ; #1 ; 

f*s TransferFcn: SubVI ; INl : input point ; OUTl : output point ;#1; 

^ 20 SubSys t em : SubVI ; INl : ; OUTl : ; # 0 ; 

7 Sum: SubVI ; INl : x ; IN2 : y ; OUTl : x+y ; #0 ; 

M* Gain: Function; INl : x; OUTl : x*y; #0; 

ft! Abs : Function; INl : x; OUTl : abs (x) ; #0 ; 

fy Scope : Terminal ; INl : ; OUTl : ; #0 ; 

n 25 Display : Terminal; INl : ;OUTl: ;#0; 

5? Inport : Terminal ; INl : ; OUTl : ; #0 ; 

^ Outport : Terminal ; INl : ; OUTl : ; #0 ; 

O Clock : SubVI ; INl : ; OUTl : Time ; #0 ; 

EOF 

30 

This translation information specifies whether each Simulink block is translated to a 
Lab VIEW SubVI (i.e., subprogram node), a Lab VIEW function node, or a Lab VIEW user 
interface terminal. There is also a specification of the inputs and outputs for the nodes. 
The "#" specifies which node terminal provides the primary signal output. 
35 Referring again to Figure 10, the script also includes a set of WIRE operations 

specifying how to interconnect the block diagram nodes created when the CREATE 
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operations were performed. Translation information such as the sample above may be 
used in wiring the nodes together appropriately. 

Figure 12 illustrates the same Lab VIEW block diagram as the block diagram of 
Figure 11. As illustrated in Figure 12 and described above, the loop among the "Sum", 

5 "Derivative", and "Integrator 1" nodes of the Simulink program is implemented in the 
Lab VIEW program through the use of a Lab VIEW local variable, such that there is no 
loop per se in the Lab VIEW program. However, the Lab VIEW block diagram nodes may 
be generated with the positioning shown in Figure 1 1 by default, so that the Lab VIEW 
block diagram more closely resembles the Simulink block diagram. 

10 Figure 13 illustrates a user interface panel automatically generated for the 

Lab VIEW program when the Lab VIEW program is programmatically generated. The 
user interface graph element shown in Figure 13 corresponds to the node labeled "Scope" 
in the Lab VIEW block diagram of Figure 11. This "Scope" node in the Lab VIEW block 
diagram corresponds to the "Scope" node in the Simulink block diagram of Figure 7. 

15 When the GPG program performs the CREATE operation for the Simulink "Scope" 
node, then the Lab VIEW "Scope" node may be included in the Lab VIEW block diagram, 
which is a Lab VIEW user interface node terminal. As a result of creating this node 
terminal in the Lab VIEW block diagram, the corresponding user interface graph element 
may be created in the Lab VIEW user interface panel. 

20 

When executed, the programmatically generated Lab VIEW graphical program of 
Figure 11 performs substantially the same as the Simulink graphical program of Figure 7. 
The Lab VIEW graphical program may be executed in any computing environment 
supported by the Lab VIEW programming development environment. Lab VIEW provides 
25 support to download Lab VIEW programs to hardware devices such as FPGA's and other 
programmable logic devices, e.g., for execution in an embedded system. Thus, in one 
embodiment, a Simulink program may be automatically converted to a LabVIEW 
program and may be downloaded to a hardware device supported by the LabVIEW 
programming development environment. 
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Programmatically Generating the Second Graphical Program 

A graphical program generation (GPG) program may generate the second graphical 
5 program in any of various ways. In one embodiment, the GPG program may be 
implemented as a self-contained program or application that includes all necessary program 
logic for generating the second graphical program. In another embodiment, the GPG 
program may comprise a client portion and a server portion (or client program and server 
program), wherein the client portion may request or direct the server portion to generate the 

10 graphical program. For example, the client portion may utilize an application programming 
interface (API) provided by the server portion in order to generate the graphical program. In 
other words, the client portion may perform calls to the API provided by the server portion, 
and the server portion may execute functions or routines bound to these calls to generate the 
second graphical program. In one embodiment, the server portion may be an instance of the 

15 second graphical programming development environment or may be an application 
associated with the second graphical programming development environment. For 
example, the Lab VIEW graphical programming development environment application 
enables client programs to interface with a Lab VIEW server in order to programmatically 
generate or modify Lab VIEW graphical programs. 

20 As used herein, the term "GPG program" is intended to include any of various 

implementations of a program (or programs) that are executable to programmatically 
generate a graphical program. For example, the term "GPG program" is intended to include 
an embodiment in which the GPG program is a self-contained program or application (not 
implemented as a client/server program) that includes all necessary program logic for 

25 programmatically generating a second graphical program based on a first graphical 
program. The term "GPG program" is also intended to include an embodiment in which a 
combination of a client portion (or client program) and server portion (or server program) 
operate together to programmatically generate the second graphical program. The term 
"GPG program" is also intended to include other program implementations. 



Arty. Dkt. No.: 5150-48000 



Page 43 



Conley, Rose & Tayon, P.C. 



As described above, the GPG client program may communicate with a GPG server 
program through an API. The server program is operable to perform the actions indicated 
by the API calls. For example, the server program may be operable to create a new 
graphical program, add objects to the graphical program, connect graphical program objects, 
5 etc. 

The GPG client program may be any of various types of programs. For example, 
the GPG client program may itself be a graphical program and may include various block 
diagram nodes operable to call a server program to create the second graphical program. 
Figures 14 - 19 illustrate portions of a client GPG graphical program. In other 
10 embodiments, the GPG client program may be a text-based program such as a C++ 
program, a Visual Basic program, a Java program, etc., or any combination of these or other 
languages. 

grj As noted above, in one embodiment, the server program is an application instance 

of the Lab VIEW graphical programming development environment. The Lab VIEW 
15 environment comprises functionality referred to as "VI (virtual instrument) Server" which 
M= enables client programs to communicate with the Lab VIEW environment. The VI Server 

J* functionality enables client programs to create or edit a Lab VIEW graphical program or VI. 

^ A client program which requests Lab VIEW to generate/edit a VI may itself be a graphical 

ry 

fy program or VI. A client VI may include particular nodes in the client VI block diagram 

j~ 20 which utilize the VI Server functionality of a Lab VIEW instance to request the Lab VIEW 

instance to create a new VI, add objects to the VI, etc. Figures 14 - 19, described below, 
illustrate one example of the use of such nodes to programmatically generate a second 
graphical program. (Lab VIEW also provides components such as ActiveX components 
which enable text-based programs such as Visual Basic programs, Visual C++ programs, 
25 etc., to access the VI Server functionality.) 

For more information on one embodiment of a system and method enabling the 
programmatic generation of a graphical program, please refer to U.S. Patent Application 
Serial No. , titled, "System and Method for Programmatically Generating a 
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Graphical Program in Response to Program Information", which was incorporated by 
reference above. 



5 Figures 14 - 19 - Graphical GPG Program 

Figures 14 - 19 illustrate portions of a GPG client program operable to translate a 
Simulink graphical program to a Lab VIEW graphical program, wherein the GPG client 
program is itself a graphical program. 

In Figure 14, the GPG client program portion obtains user input such as path 
10 names for a model file for the Simulink program to be translated and the Lab VIEW 
program to be generated and then executes three subprograms, which respectively analyze 
^ the Simulink model file to create a directed graph representation, create a script file 

d3 specifying creation of the Lab VIEW program, and perform the operations specified in the 

^ script file. Also, once the Lab VIEW program is generated, it may be executed, printed, or 

5=5 I 

1 ~ 15 saved, depending on specified user input. 

M Figure 15 illustrates a portion of the GPG client program to analyze the Simulink 

7" model file and construct the directed graph representation. This portion of the GPG 

is 

program implements the method of Figure 6. 
FU Figure 16 illustrates a portion of the GPG client program to implement a 

n 20 CREATE script operation to create a properly configured Lab VIEW block diagram node. 

^ For each type of node to be created, this portion of the GPG client program may 

implement separate cases (not shown). 

Figure 17 illustrates a portion of the GPG client program to implement a 
CREATE_LOCAL script operation, e.g., to avoid a loop in the Lab VIEW program 
25 through the use of a local variable node, as described above. 

Figure 18 illustrates a portion of the GPG client program to implement an 
INITIAI IZEJLOC ALS script operation to initialize local variable values so that the 
Lab VIEW program executes correctly across multiple executions. 
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Figure 19 illustrates a portion of the GPG client program to implement a WIRE 
script operation to connect two Lab VIEW block diagram nodes. 

Although the embodiments above have been described in considerable detail, 
numerous variations and modifications will become apparent to those skilled in the art 
once the above disclosure is fully appreciated. It is intended that the following claims be 
interpreted to embrace all such variations and modifications. 
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